SRE-938: Fix npm vulnerabilities from the 2026-08-10 scan - #9182

Requested by Tim Diekmann · Slack thread

🌟 What is the purpose of this PR?

Closes 25 of the 26 open npm vulnerability findings the 2026-08-10 weekly scan reported against this repo, in one PR, and supersedes four Renovate security PRs that cannot merge.

Before: yarn.lock carried vulnerable copies of nine packages. Most of them are transitive dependencies whose parents' semver ranges already allow a patched release — they were simply never re-resolved. The rest were held down by direct version pins and by root resolutions entries.

After: the lockfile has been re-resolved and deduped, and the four pins/resolutions that were blocking the remaining upgrades have been moved. Every vulnerable version listed below is now absent from yarn.lock — not merely accompanied by a newer entry (see the gone-check below).

Why this replaces the four Renovate PRs

#9173 (postcss), #9175 (js-yaml), #9180 (dompurify) and #9181 (nanoid) each change package.json and leave yarn.lock untouched, so every Yarn step in CI aborts. Renovate's own artifact-update comment on each names the cause: this repo declares packageManager: yarn@4.16.0, but the Renovate runner's global Yarn is 1.22.22 with Corepack disabled, so it cannot write a Yarn Berry lockfile. This is the same standing runner defect first seen on internal-sites (#198/#199/#200) on 2026-08-06; it is now reproducing here. Fixing the runner is out of scope for this PR and is worth its own ticket.

Two of them also needed correcting, not just relocking:

• #9173 is incomplete. The root package.json has two postcss resolutions, next/postcss and postcss@npm:8.5.14. The PR bumps only the first, so the vulnerable 8.5.18 copy would have survived and GHSA-fxqj-rqcc-2cmp would have stayed open. Both are moved here.
• #9181 takes two majors. It moves @apps/hash-api's exact nanoid pin from 3.3.11 straight to 5.1.16. nanoid 5 is ESM-only (no main, no CJS entry point) with a Node ≥18 floor, whereas 3.3.17 keeps the dual main: index.cjs / module: index.js layout that 3.3.11 has. 3.3.17 closes both nanoid advisories on its own, so there is no reason to take a major inside a security fix — and it lets the pinned copy collapse into the same lockfile entry as the transitive nanoid@npm:^3.0.0 / ^3.3.16 range instead of adding a third one. If nanoid 5 is wanted in hash-api, that belongs in a separate non-security PR.

🔗 Related links

• Linear: SRE-938 (internal)
• Supersedes Update npm package postcss to v8.5.23 [SECURITY] #9173, Update npm package js-yaml to v4.3.1 [SECURITY] #9175, Update npm package dompurify to v3.4.13 [SECURITY] #9180, Update npm package nanoid to v5 [SECURITY] #9181

🚫 Blocked by

• Nothing

🔍 What does this change?

Manifest changes — direct pins and resolutions that were blocking a patched resolution:

Lockfile-only changes — transitive dependencies whose parents already admitted the fix, so no manifest change was needed:

Regenerated with yarn install followed by yarn dedupe --strategy highest; yarn lint:yarn-deduplicate reports nothing left to dedupe. Targets are the highest release the repo's npmMinimalAgeGate: 5d admits, which is why postcss stops at 8.5.25 rather than 8.5.26, hono at 4.13.0 rather than 4.13.1, nanoid at 3.3.17 rather than 3.3.18 and ip-address at 10.4.0 rather than 10.5.0. No gate override was needed — every version above is more than five days old.

Why the resolutions stay resolutions

Per the "bump the pinning parent before adding or keeping an override" rule, each remaining override was re-checked against the registry:

• next/postcss — next 15.5.x still exact-pins postcss 8.4.31 in every release up to the current 15.5.23. Only next 16.3.0 moves to 8.5.23, and that is a major upgrade of Next, not a security fix.
• postcss@npm:8.5.14 — this descriptor comes from PandaCSS (@pandacss/core, @pandacss/generator, @pandacss/node, @pandacss/postcss). The current latest, 1.12.0, still exact-pins postcss 8.5.14.
• @redocly/openapi-core/js-yaml — the repo is on @redocly/openapi-core@^1.34.6. The newest 1.x, 1.34.18, pins js-yaml 4.3.0, which is itself the vulnerable version; only the 2.x major moves to js-yaml ^5.2.2.
• dompurify — kept global because monaco-editor@0.55.1 pulls in dompurify 3.2.7, which is affected by this advisory and several older ones. The resolution collapses it onto the patched copy.

Gone-check

Every vulnerable version has zero resolution: entries in the new yarn.lock:

brace-expansion@npm:1.1.17   0      nanoid@npm:3.3.11       0
brace-expansion@npm:2.1.3    0      nanoid@npm:3.3.16       0
brace-expansion@npm:5.0.8    0      nanoid@npm:5.1.6        0
dompurify@npm:3.4.12         0      postcss@npm:8.5.14      0
dompurify@npm:3.2.7          0      postcss@npm:8.5.18      0
fast-uri@npm:3.1.4           0      postcss@npm:8.5.22      0
hono@npm:4.12.29             0      undici@npm:7.28.0       0
ip-address@npm:10.2.0        0      js-yaml@npm:3.15.0      0
js-yaml@npm:4.2.0            0      js-yaml@npm:4.3.0       0

The yarn.lock diff is +48/−68: entries are removed, not merely added. Re-running the whole lockfile through npm's bulk advisory endpoint before and after the change shows 23 advisory rows closed and zero new ones.

Advisories closed

Pre-Merge Checklist 🚀

🚢 Has this modified a publishable library?

This PR:

• does not modify any publishable blocks or libraries, or modifications do not need publishing

📜 Does this require a change to the docs?

The changes in this PR:

• are internal and do not require a docs change

🕸️ Does this require a change to the Turbo Graph?

The changes in this PR:

• do not affect the execution graph

⚠️ Known issues

esbuild 0.27.7 (GHSA-g7r4-m6w7-qqqr, low) is the one finding this PR does not close, and it is deliberately left alone. tsup's latest release (8.5.1) still declares esbuild: ^0.27.0, and vite@7.3.5 and storybook 9.x/10.x also cap at ^0.27.0, so 0.28.1 is unreachable without forcing an override past several parents' declared ranges. Unchanged from the 2026-07-20 assessment.

🐾 Next steps

• Close Update npm package postcss to v8.5.23 [SECURITY] #9173, Update npm package js-yaml to v4.3.1 [SECURITY] #9175, Update npm package dompurify to v3.4.13 [SECURITY] #9180 and Update npm package nanoid to v5 [SECURITY] #9181 once this is green.
• The Renovate runner cannot regenerate Yarn Berry lockfiles (global Yarn 1.22.22, Corepack disabled). Until that is fixed, every lockfile-bearing Renovate PR on this repo and on internal-sites will land broken and need this same manual repair. Worth its own ticket.

🛡 What tests cover this?

The existing CI suite. There are no source changes — only dependency versions — so the signal is that lint, typecheck, unit, integration and the Docker/Vercel builds all still pass against the re-resolved tree.

❓ How to test this?

1. Check out the branch and run yarn install --immutable — it should complete without rewriting the lockfile.
2. Run yarn lint:yarn-deduplicate — it should report nothing to dedupe.
3. Grep yarn.lock for any of the versions in the gone-check table above — there should be no matches.